The type of system and/or development approach and/or test policy determine which forms of which test levels are best
used. For iterative system development, for instance, a thorough acceptance test is less obvious. This is because the
quality from the user perspective has already been tested in previous test levels. However, for package implementations
there is a far greater emphasis on a thorough acceptance test. The risks here are focused on the implementation of the
package in the organisation, a typical acceptance test aspect.
Development tests and evaluation levels
Please note that it is important to include the development tests and evaluation levels in the master test plan,
because this offers a range of opportunities to optimise the overall process. Both development tests and
evaluations occur earlier on in the system development than the system and acceptance tests. As such they are able to
detect defects earlier and closer to the source – for evaluations even before the defects are implemented in the
software. This means that rework costs are lower and advice on the quality of the system can be provided at an earlier
stage. Hence, it is clearly preferable to include the evaluation levels in the plan. To avoid using ‘testing and
evaluation’ in this chapter, we only use the term ‘testing’. This explicitly includes evaluation.
Alignment undesirable?
It is possible that the party responsible for a specific test level perceives the alignment as an undesirable influence
on the part of other parties on its own test (whether rightly or wrongly). However, it is still useful to try including
this test level in the master test plan because the master test plan may visualise, in an explicit manner, a double
test of the same aspect or a missing test of an aspect. If, for instance, a third party develops and system tests the
system - as often happens with outsourcing - there may not sometimes be sufficient opportunities to align the test
levels in advance. The master test plan must then include the requirements defined for the test levels at the supplier.
In addition to requirements concerning the required test strategy, these may also include the delivery of testware,
test results and reports. The master test plan then also serves as a communication tool to this party.
|
